…en corruption

Narrow dsr1-fp4-mi355x-sglang-disagg-8k1k-mtp search-space to a single
DEP8+MTP3 conc-64 entry. With max(CONC_LIST)=64, the server computes
SGLANG_MORI_NUM_MAX_DISPATCH_TOKENS_PER_RANK=32, which is below the 256
threshold that selects the correct All2All kernel. Expected: ~0% gsm8k
(silent corruption from the low-latency All2All variant).

Not for merge — throwaway validation of the dispatch token bug.

Clamp MORI_MAX_DISPATCH_TOKENS_DECODE to minimum 256 when DP+EP are
both enabled, preventing SGLang's low-latency All2All kernel from being
selected. That kernel silently corrupts outputs at small buffer sizes.

Run A of A/B test: benchmark + eval WITH clamp on conc-64 DEP8+MTP3.

Run B of A/B test: benchmark + eval WITHOUT dispatch token clamp.
MORI_MAX_DISPATCH_TOKENS_DECODE will be 32 (<256 threshold).
Expected: corrupted output, inflated AL, ~0% gsm8k.

… benchmark+eval at conc-64

Validates Option A: instead of clamping the env var, patch the installed
SGLang moriep.py at runtime to enforce a minimum of 64 (AMD CDNA3/4
warpSize) on num_max_dispatch_tokens_per_rank before it reaches the MoRI
kernel config. If gsm8k recovers (like the 256 clamp did), this confirms
warpSize is the minimum viable buffer floor and scopes the upstream fix.

…val at conc-64

Root cause: the MoRI All2All dispatch kernel (EpDispatchInterNodeV1Kernel /
IntraNode) writes dispatched tokens into warpSize-aligned receive slots
(destTokId = flagSlotId*warpSize + laneId, laneId 0..63), so each warp-chunk
spans 64 (CDNA3/4 wavefront) token slots. The per-rank receive region is sized
to maxNumInpTokenPerRank, which the harness derives as max(CONC_LIST)/TP*(MTP+1).
At low concurrency this collapses below 64 (conc-64/TP8/MTP3 -> 64/8*4 = 32), so
a single chunk overruns the 32-slot region -> silent out-of-bounds writes ->
semantically corrupt output (decodes fine, gsm8k=0).

Confirmed from the conc-64 Run B decode log: INTER_KERNEL_SWITCH=16 with
DISPATCH_TOKENS=32 selects the NON-LL InterNodeV1 kernel (32 > 16), yet output
was still corrupt -> the bug is the buffer-size floor, not the LL-vs-non-LL
kernel choice.

Fix: clamp MORI_MAX_DISPATCH_TOKENS_DECODE to >= 64 after the MTP multiply.
Only raises the value at low conc; adds a few MB of staging buffer but no
compute, so real throughput is unchanged (the ~3% edge of the corrupt run was
an artifact of dropping work). 64 is the principled minimum vs the proven-but-
larger 256.

…-eval

# Conflicts:
#	perf-changelog.yaml

…ent)

The conc-64 run with the warpSize floor (64) still scored gsm8k=0.00
(run 26919517564), disproving the one-wavefront hypothesis. The per-rank
dispatch buffer must hold the routing fan-in (a receiving rank takes tokens
from all worldSize peers), not just one warp-chunk. Empirically on MI355X:
dispatch=32 -> 0.00, dispatch=64 -> 0.00, dispatch>=256 -> 0.94. Clamp to the
proven 256. Throughput is unchanged; the corrupt run's ~3% edge was dropped
work, not real speed.

The vendor image installs sglang as a namespace package where
__file__ is None.  os.path.dirname(None) throws TypeError, so the
patcher crashed and the floor was never applied — eval ran unpatched.

Fall through __file__ → __path__ → importlib.util.find_spec() to
locate the package directory robustly.

The vendor image installs sglang at /sgl-workspace/sglang/ but the
actual Python package is under python/sglang/ within that tree.
When __path__ returns the repo root, the patcher couldn't find
moriep.py. Add candidate paths and a bounded walk fallback.

The formula divided BENCH_MAX_CONC_VALUE by decode_dp_ranks, assuming
--max-running-requests is a global limit split across DP ranks. It is
actually per-rank: each of the 8 DP schedulers independently allows up
to BENCH_MAX_CONC_VALUE requests. At conc-64/TP8/MTP3 the old formula
produced dispatch=32 (64/8*4), but each rank can hold 64*4=256 tokens,
causing 8x buffer overflow in MoRI's intra-node dispatch kernel (the
only guard is an assert compiled out under -DNDEBUG) and silent
corruption (gsm8k=0).